Komunikacja międzyźródłowa: Wzorce bezpieczeństwa z PostMessage API

We współczesnym internecie aplikacje często muszą wchodzić w interakcje z zasobami z różnych źródeł. Same-Origin Policy (SOP) to kluczowy mechanizm bezpieczeństwa, który ogranicza skryptom dostęp do zasobów z innego źródła. Istnieją jednak uzasadnione scenariusze, w których komunikacja międzyźródłowa jest konieczna. API postMessage zapewnia kontrolowany mechanizm do osiągnięcia tego celu, ale kluczowe jest zrozumienie jego potencjalnych zagrożeń bezpieczeństwa i wdrożenie odpowiednich wzorców bezpieczeństwa.

Zrozumienie Same-Origin Policy (SOP)

Same-Origin Policy to fundamentalna koncepcja bezpieczeństwa w przeglądarkach internetowych. Ogranicza ona strony internetowe przed wysyłaniem żądań do domeny innej niż ta, która dostarczyła stronę. Źródło (origin) jest definiowane przez schemat (protokół), hosta (domenę) i port. Jeśli którykolwiek z tych elementów się różni, źródła są uważane za różne. Na przykład:

• https://example.com
• https://www.example.com
• http://example.com
• https://example.com:8080

Wszystkie te adresy są różnymi źródłami, a SOP ogranicza bezpośredni dostęp skryptów między nimi.

Wprowadzenie do PostMessage API

API postMessage zapewnia bezpieczny i kontrolowany mechanizm komunikacji międzyźródłowej. Pozwala skryptom na wysyłanie wiadomości do innych okien (np. ramek iframe, nowych okien lub kart), niezależnie od ich źródła. Okno odbierające może następnie nasłuchiwać na te wiadomości i odpowiednio je przetwarzać.

Podstawowa składnia wysyłania wiadomości to:

otherWindow.postMessage(message, targetOrigin);

• otherWindow: Odniesienie do okna docelowego (np. window.parent, iframe.contentWindow lub obiekt okna uzyskany z window.open).
• message: Dane, które chcesz wysłać. Może to być dowolny obiekt JavaScript, który można serializować (np. ciągi znaków, liczby, obiekty, tablice).
• targetOrigin: Określa źródło, do którego chcesz wysłać wiadomość. Jest to kluczowy parametr bezpieczeństwa.

Po stronie odbiorczej należy nasłuchiwać na zdarzenie message:

window.addEventListener('message', function(event) {
  // ...
});

Obiekt event zawiera następujące właściwości:

• event.data: Wiadomość wysłana przez drugie okno.
• event.origin: Źródło okna, które wysłało wiadomość.
• event.source: Odniesienie do okna, które wysłało wiadomość.

Zagrożenia i podatności bezpieczeństwa

Chociaż postMessage oferuje sposób na obejście ograniczeń SOP, wprowadza również potencjalne zagrożenia bezpieczeństwa, jeśli nie jest starannie zaimplementowane. Oto kilka typowych podatności:

1. Niezgodność docelowego źródła (Target Origin)

Brak walidacji właściwości event.origin jest krytyczną podatnością. Jeśli odbiorca ślepo ufa wiadomości, każda strona internetowa może wysłać złośliwe dane. Zawsze weryfikuj, czy event.origin pasuje do oczekiwanego źródła przed przetworzeniem wiadomości.

Przykład (Podatny kod):

window.addEventListener('message', function(event) {
  // NIE RÓB TEGO!
  processMessage(event.data);
});

Przykład (Bezpieczny kod):

window.addEventListener('message', function(event) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('Received message from untrusted origin:', event.origin);
    return;
  }

  processMessage(event.data);
});

2. Wstrzykiwanie danych (Data Injection)

Traktowanie otrzymanych danych (event.data) jako kodu wykonywalnego lub bezpośrednie wstrzykiwanie ich do DOM może prowadzić do podatności Cross-Site Scripting (XSS). Zawsze odkażaj (sanitise) i waliduj otrzymane dane przed ich użyciem.

Przykład (Podatny kod):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    document.body.innerHTML = event.data; // NIE RÓB TEGO!
  }
});

Przykład (Bezpieczny kod):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    const sanitizedData = sanitize(event.data); // Zaimplementuj odpowiednią funkcję odkażania
    document.getElementById('message-container').textContent = sanitizedData;
  }
});

function sanitize(data) {
    // Zaimplementuj tutaj solidną logikę odkażania.
    // Na przykład, użyj DOMPurify lub podobnej biblioteki
    return DOMPurify.sanitize(data);
}

3. Ataki typu Man-in-the-Middle (MITM)

Jeśli komunikacja odbywa się przez niezabezpieczony kanał (HTTP), atakujący MITM może przechwycić i zmodyfikować wiadomości. Zawsze używaj HTTPS do bezpiecznej komunikacji.

4. Cross-Site Request Forgery (CSRF)

Jeśli odbiorca wykonuje działania na podstawie otrzymanej wiadomości bez odpowiedniej walidacji, atakujący mógłby potencjalnie sfałszować wiadomości, aby skłonić odbiorcę do wykonania niezamierzonych działań. Wdróż mechanizmy ochrony przed CSRF, takie jak dołączenie tajnego tokenu do wiadomości i weryfikacja go po stronie odbiorcy.

5. Używanie symboli wieloznacznych (wildcard) w targetOrigin

Ustawienie targetOrigin na * pozwala każdemu źródłu na otrzymanie wiadomości. Należy tego unikać, chyba że jest to absolutnie konieczne, ponieważ niweczy to cel bezpieczeństwa opartego na źródle. Jeśli musisz użyć *, upewnij się, że wdrożyłeś inne silne środki bezpieczeństwa, takie jak kody uwierzytelniania wiadomości (MAC).

Przykład (Unikaj tego):

otherWindow.postMessage(message, '*'); // Unikaj używania '*' chyba że jest to absolutnie konieczne

Wzorce bezpieczeństwa i najlepsze praktyki

Aby złagodzić ryzyka związane z postMessage, postępuj zgodnie z poniższymi wzorcami bezpieczeństwa i najlepszymi praktykami:

1. Ścisła walidacja źródła

Zawsze waliduj właściwość event.origin po stronie odbiorcy. Porównuj ją z predefiniowaną listą zaufanych źródeł. Używaj ścisłego porównania (===) do porównania.

2. Odkażanie (sanitacja) i walidacja danych

Odkażaj i waliduj wszystkie dane otrzymane przez postMessage przed ich użyciem. Stosuj odpowiednie techniki odkażania w zależności od tego, jak dane będą używane (np. escapowanie HTML, kodowanie URL, walidacja danych wejściowych). Używaj bibliotek takich jak DOMPurify do odkażania HTML.

3. Kody uwierzytelniania wiadomości (MAC)

Dołącz kod uwierzytelniania wiadomości (MAC) do wiadomości, aby zapewnić jej integralność i autentyczność. Nadawca oblicza MAC przy użyciu współdzielonego tajnego klucza i dołącza go do wiadomości. Odbiorca ponownie oblicza MAC przy użyciu tego samego współdzielonego tajnego klucza i porównuje go z otrzymanym MAC. Jeśli pasują, wiadomość jest uważana za autentyczną i niezmienioną.

Przykład (Użycie HMAC-SHA256):

// Nadawca
async function sendMessage(message, targetOrigin, sharedSecret) {
  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(message));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  const securedMessage = {
    data: message,
    signature: signatureHex
  };

  otherWindow.postMessage(securedMessage, targetOrigin);
}

// Odbiorca
async function receiveMessage(event, sharedSecret) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('Received message from untrusted origin:', event.origin);
    return;
  }

  const securedMessage = event.data;
  const message = securedMessage.data;
  const receivedSignature = securedMessage.signature;

  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(message));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["verify"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  if (signatureHex === receivedSignature) {
    console.log('Message is authentic!');
    processMessage(message); // Kontynuuj przetwarzanie wiadomości
  } else {
    console.error('Message signature verification failed!');
  }
}

Ważne: Współdzielony tajny klucz musi być bezpiecznie wygenerowany i przechowywany. Unikaj hardkodowania klucza w kodzie.

4. Używanie Nonce i znaczników czasu

Aby zapobiec atakom powtórzeniowym (replay attacks), dołącz do wiadomości unikalny nonce (number used once - liczba użyta raz) i znacznik czasu. Odbiorca może wtedy zweryfikować, czy nonce nie został wcześniej użyty i czy znacznik czasu mieści się w akceptowalnym przedziale czasowym. Zmniejsza to ryzyko, że atakujący ponownie odtworzy wcześniej przechwycone wiadomości.

5. Zasada najmniejszych uprawnień

Nadawaj tylko minimalne niezbędne uprawnienia drugiemu oknu. Na przykład, jeśli drugie okno potrzebuje tylko odczytywać dane, nie pozwalaj mu na ich zapisywanie. Projektuj swój protokół komunikacyjny z myślą o zasadzie najmniejszych uprawnień.

6. Content Security Policy (CSP)

Użyj Content Security Policy (CSP), aby ograniczyć źródła, z których mogą być ładowane skrypty, oraz działania, które skrypty mogą wykonywać. Może to pomóc w złagodzeniu skutków podatności XSS, które mogą wynikać z niewłaściwej obsługi danych postMessage.

7. Walidacja danych wejściowych

Zawsze waliduj strukturę i format otrzymanych danych. Zdefiniuj jasny format wiadomości i upewnij się, że otrzymane dane są z nim zgodne. Pomaga to zapobiegać nieoczekiwanemu zachowaniu i podatnościom.

8. Bezpieczna serializacja danych

Używaj bezpiecznego formatu serializacji danych, takiego jak JSON, do serializacji i deserializacji wiadomości. Unikaj używania formatów, które pozwalają na wykonanie kodu, takich jak eval() lub Function().

9. Ogranicz rozmiar wiadomości

Ogranicz rozmiar wiadomości wysyłanych przez postMessage. Duże wiadomości mogą zużywać nadmierne zasoby i potencjalnie prowadzić do ataków typu denial-of-service.

10. Regularne audyty bezpieczeństwa

Przeprowadzaj regularne audyty bezpieczeństwa swojego kodu, aby zidentyfikować i usunąć potencjalne podatności. Zwracaj szczególną uwagę na implementację postMessage i upewnij się, że wszystkie najlepsze praktyki bezpieczeństwa są przestrzegane.

Przykładowy scenariusz: Bezpieczna komunikacja między ramką Iframe a jej rodzicem

Rozważmy scenariusz, w którym ramka iframe hostowana na https://iframe.example.com musi komunikować się ze swoją stroną nadrzędną hostowaną na https://parent.example.com. Ramka iframe musi wysłać dane użytkownika do strony nadrzędnej w celu ich przetworzenia.

Iframe (https://iframe.example.com):

// Wygeneruj współdzielony klucz tajny (zastąp bezpieczną metodą generowania klucza)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

// Pobierz dane użytkownika
const userData = {
  name: 'John Doe',
  email: 'john.doe@example.com'
};

// Wyślij dane użytkownika do strony nadrzędnej
async function sendUserData(userData) {
  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(userData));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  const securedMessage = {
    data: userData,
    signature: signatureHex
  };
  parent.postMessage(securedMessage, 'https://parent.example.com');
}

sendUserData(userData);

Strona nadrzędna (https://parent.example.com):

// Współdzielony klucz tajny (musi pasować do klucza z ramki iframe)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

window.addEventListener('message', async function(event) {
  if (event.origin !== 'https://iframe.example.com') {
    console.warn('Received message from untrusted origin:', event.origin);
    return;
  }

  const securedMessage = event.data;
  const userData = securedMessage.data;
  const receivedSignature = securedMessage.signature;

  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(userData));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["verify"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');


  if (signatureHex === receivedSignature) {
    console.log('Message is authentic!');
    // Przetwórz dane użytkownika
    console.log('User data:', userData);
  } else {
    console.error('Message signature verification failed!');
  }
});

Ważne uwagi:

• Zastąp YOUR_SECURE_SHARED_SECRET bezpiecznie wygenerowanym współdzielonym kluczem tajnym.
• Współdzielony klucz tajny musi być taki sam zarówno w ramce iframe, jak i na stronie nadrzędnej.
• Ten przykład używa HMAC-SHA256 do uwierzytelniania wiadomości.

Podsumowanie

API postMessage to potężne narzędzie umożliwiające komunikację międzyźródłową w aplikacjach internetowych. Jednakże, kluczowe jest zrozumienie potencjalnych zagrożeń bezpieczeństwa i wdrożenie odpowiednich wzorców bezpieczeństwa w celu ich złagodzenia. Postępując zgodnie z wzorcami bezpieczeństwa i najlepszymi praktykami opisanymi w tym przewodniku, możesz bezpiecznie używać postMessage do tworzenia solidnych i bezpiecznych aplikacji internetowych.

Pamiętaj, aby zawsze priorytetowo traktować bezpieczeństwo i być na bieżąco z najnowszymi najlepszymi praktykami w zakresie tworzenia stron internetowych. Regularnie przeglądaj swój kod i konfiguracje bezpieczeństwa, aby upewnić się, że Twoje aplikacje są chronione przed potencjalnymi podatnościami.